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DECISION ON APPEAL 



1 The two-month time period for filing an appeal or commencing a 
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided 
date shown on this page of the decision. The time period does not run from 
the Mail Date (paper delivery) or Notification Date (electronic delivery). 
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STATEMENT OF THE CASE 
This is an appeal under 35 U.S.C. § 134(a) from the Examiner's 
rejection of claims 1-18, which are all of the pending claims. 
We have jurisdiction under 35 U.S.C. § 6(b). We affirm. 

A. Appellants ' invention 

Appellants' invention relates to remote service delivery for computer 
networks. Specification 2:24-25. 

By way of background, Appellants explain that in a remote services 
system, often large numbers of messages are sent to multiple destinations of 
the customer, for example, when a remote services system needs to push a 
software update to all of the customer components. Id. at 3:9-12. The 
transfer of a large number of messages from the remote services system to a 
customer site may waste network resources, as these messages tend to be 
large (e.g., several Mbytes of data). Id. at 3:12-14. 

Appellants' Figure 11 is reproduced below. 
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Figure 1 1 shows a flow diagram of communications within a remote 
services architecture. Id. at 19:17-18. Communications within the remote 
service architecture involve three tiers: a remote services proxy tier 1110, an 
intermediate MLM (mid level manager 2 ) tier 1112, and an application MLM 
and server tier 1114. Id. at 19:19-21. Communication is established and 
connections are made from the bottom tier (the remote services proxy tier) to 
the top tier. Id. at 19:21-22. 

In Appellants' method, when a message is originated at an application 
server of the remote services system for a group of destinations, a single 
instance of a message is transferred from the application server to an 
intermediate MLM on the path of the group of components. Id. at 3:19-22. 



2 Specification 8:9. 
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The intermediate MLM duplicates the message for all of the final 
destinations and transmits the message. Id. at 3:22-23. Thus, the network 
resources used between the application server and the multiple destinations 
are minimized as no redundant transfer occurs between the application 
server and the intermediate MLM. Id. at 3:23-25. 

In one embodiment, to which the claims are directed, the invention 
relates to communicating in a remote services system that includes a forward 
channel communication and a back-channel communication. Id. at 3:28-30. 
The forward channel communicates using a forward channel 
communication path and the back-channel communicates using a back- 
channel communication path, which is established only after a forward 
channel communication path is established. Id. at 3:30-33. The back- 
channel communication path is used to multicast a message to a group of 
components. Id. at 3:33-34. 

B. The claims 

The independent claims are claims 1, 7, and 13, of which claim 1 

reads: 

1 . A method of communicating in a remote services system 
comprising: 

communicating a forward channel communication using 
a forward channel communication path; 

communicating a back-channel communication using a 
back-channel communication path, the back-channel 
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communication path being established only after a forward 
channel communication path is established; and 

using the back-channel communication path to multicast 
a message to a group of remote service components. 

Claims App., Br. 16 (formatting modified). 3 

Claim 7 reads as follows: 

7. A method of communicating in a remote services 
system comprising: 

assigning a plurality of remote service components 
within the remote services system with a respective plurality of 
unique remote services identifiers; 

communicating a forward channel communication using 
a forward channel communication path; 

communicating a back-channel communication using a 
back-channel communication path; and 

using the back-channel communication path to multicast 
a message to a group of remote services components based 
upon unique remote services identifiers corresponding to 
components of the group of remote service components. 

August 3, 2005, "Response to Non-final Office Action" at 4-5 (formatting 
modified). 4 



3 References herein to the Brief are to the Amended Brief filed 
January 14, 2008. No Reply Brief was filed. 

4 As noted in the Answer (at 3), the copy of claim 7 as reproduced in 
the Claims Appendix (Br. 16-17) is inaccurate because it corrects the second 
(Continued on next page.) 



5 



Appeal 2008-3105 
Application 10/067,165 

C. The references and rejections 

The Examiner relies on the following references: 

Kamentsky et al. (Kamentsky) US 2002/0065929 May 30, 2002 

Dyer et al. (Dyer) US 6,349,340 Bl Feb. 19, 2002 

Claims 1, 2, 5-8, 11-14, 17, and 18 stand rejected under 35 U.S.C. 
§ 102(e) for anticipation by Dyer. Answer 4. 

Claims 3, 4, 9, 10, 15, and 16 stand rejected under § 103(a) for 
obviousness over Dyer in view of Kamentsky. Id. at 7. 

Claims 7-12 further stand rejected under § 1 12, second paragraph, for 
being indefinite due to the above-noted inconsistency in the use of the terms 
"remote service" and "remote services" in claim 7. Id. at 4. 

In the Brief, Appellants state that "[t]he rejections of Claims 1, 7, and 
13 under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 
6,349,340 by Dyer are the only rejections at issue in this Appeal" (Br. 3) and 
thus argue the merits of only the § 102(e) rejection of independent claims 1, 
7, and 13. Id. at 3. However, Appellants further explain that "[a]s claims 2- 
6, 8-12 and 14-18 depend from claims 1, 7 and 13 respectively, the rejection 
of these claims under 35 U.S.C. § 102(e) or 35 U.S.C. § 103(a) is also 
without foundation" (id. at 15), making it clear that Appellants do not intend 
to concede the unpatentability of claims 2-6, 8-12 and 14-18 under § 102(e) 
or § 103(a). We are accordingly treating the rejections of those dependent 



of the three underlined phrases to read "remote service." 
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claims as standing or falling with the § 102(e) rejection of respective parent 
claims 1, 7, and 13. 

Appellants' discussion of the § 102(e) rejection of claims 1, 7, and 13 
addresses those claims in two groups, the first group consisting of claim 1 
(Br. 10-13) and the second group consisting of claims 7 and 13. Id. at 13-15. 

Regarding the § 1 12 rejection of claims 7-12, Appellants state: 

The Appellant acknowledges a typographical error in 
claim 7 fostering a rejection of claims 7-12 under 35 U.S.C. 
§ 1 12. While not an issue for the purposes of this appeal, 
Appellant acknowledges the mistake and upon resolution of this 
appeal will propose an amendment to rectify this deficiency. 

Br. 3. Because Appellants have not shown error in the Examiner's § 1 12 
rejection of claims 7-12, we are summarily affirming their rejection on that 
ground. 

THE ISSUE 

Appellants have the burden to show reversible error by the Examiner 
in maintaining the rejections. See In re Kahn, 441 F.3d 977, 985-86 (Fed. 
Cir. 2006) ("On appeal to the Board, an applicant can overcome a rejection 
by showing insufficient evidence of prima facie obviousness or by rebutting 
the prima facie case with evidence of secondary indicia of 
nonobviousness.") (quoting In re Roujfet, 149 F.3d 1350, 1355 (Fed. Cir. 
1998)). 

The sole issue is whether Appellants have shown that the Examiner 

erred in reading the claimed "forward channel communication using a 
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forward channel communication path" on Dyer's communication of a 
request for data from a client node to a server and in reading the claimed 
"back-channel communication using a back-channel communication path" 
on Dyer' s communication of the requested data over a source 
communication channel to a plurality of client nodes. 

PRINCIPLES OF LAW 
"To anticipate a claim, a prior art reference must disclose every 
limitation of the claimed invention, either explicitly or inherently." In re 
Schreiber, 128 F.3d 1473, 1477 (Fed. Cir. 1997). 

ANALYSIS 

Dyer discloses a method for providing improved performance in 
networks using multicast technology. Dyer, col. 1, 11. 14-16. 

Dyer's Figure 1 shows a plurality of client computers 2 connected 
through a LAN 4 to a server 6 (id., col. 4, 11. 23-27), which is an application 
server computer system having a network operating system for serving files 
for clients connected to the network 4. Id, col. 5, 11. 29-31. 

Dyer's Figure 3 is reproduced below. 
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FIG. 3 

Figure 3 is a high level architecture of a typical network client node 2 

in Figure 1 showing network application software 20 and network interface 

circuitry 10 (id., col. 5, 11. 41-43), labeled "TCP/IP Hardware" in Figure 3. 

Requests for data are initiated by processes 28. See id., col. 5, 11. 52-53 

("[E]ach process 28 can request data cataloged in the data distribution 

library 26.") (holding omitted). 

The interface circuitry 10 includes up to sixty-four addressable 
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channels 22 for receiving and transmitting data streams onto the LAN 4. Id., 
col. 6, 11. 15-18. The data distribution manager 24 distributes only the 
requested data to the requesting processes 28 by performing filtering in the 
TCP/IP hardware 10 (i.e., by disabling unwanted channels) and by 
performing software filtering in data distribution manager 24. Id., col. 7, 11. 
7-10. The hardware channels 22 to be enabled and disabled are determined 
either statically or dynamically by data distribution manager 24. Id., col. 7, 
11. 10-19. In the static solution, a configuration file can be created in the data 
distribution manager 24 to include a static mapping of data domains 
corresponding to the requested data to hardware channels 22. Id., col. 7, 11. 
20-23. Thus, upon a request for data by a process 28, the data distribution 
manager 24 need only consult the configuration file to determine an 
appropriate channel 22 to enable in the interface circuitry 10. Id., col. 7, 
11. 23-26. 

Several dynamic solutions are disclosed {id., col. 7, 11. 35-36). In one 
dynamic solution, apparently relied on by the Examiner, "the data 
distribution manager 24 can receive a point-to-point message from the 
source of the requested data identifying an appropriate channel 22 though 
which the data distribution manager 24 can receive the requested data." Id., 
col. 7, 11. 36-40 (holding omitted). See also id., col. 2, 11. 47-50; id., col. 7, 
11. 15-19. The message identifying an appropriate channel presumably is 
issued in response to a request for data communicated over a channel 22 
from the client to the server. Although the Examiner did not specifically 
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rely on the above-cited passages addressing a dynamic solution, those 

passages appear to provide the basis for Dyer's statement that "[e]ach of the 

requests for data and requested data can be communicated between the 

processes 28 and the LAN 4 through channels 22 leading to and from the 

interface circuitry 10" {id., col. 5, 11. 54-57) (holding omitted, emphasis 

added), on which statement the Examiner does rely, citing it as a basis for 

finding that the claimed "communicating a forward channel communication 

using a forward channel communication path" reads on Dyer's use of a 

"channel for receiving client request or subscription for multicast." Final 

Action 3, para. 7b. Also, the Examiner specifically explains that "Dyer's 

disclosure includes the teachings of processes and steps of a source server 

receiving requests from client nodes for data, establishing a source 

communication channel with the client nodes and multicast the requested 

data to client nodes." Answer 8-9 (emphasis added). It is therefore clear 

that the request on which the Examiner reads the claimed "forward channel 

communication" is the request for data communicated from the client node 

though channels 22 to the server and not the "request" referred to in the 

following passage, which is a request for data sent by a process 28 to the 

data distribution manager 24 within a client node: 

The method can include receiving from a process in a 
client node a request for multicast data; identifying a source for 
the requested multicast data; determining a source 
communications channel for receiving the requested multicast 
data; enabling the source communications channel; receiving 
the multicast data through the source communications channel; 
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and, forwarding the multicast data to the requesting client node 
process. 

Dyer, col. 2, 11.31-38. 

The Examiner reads the claimed "back-channel communication using 
a back-channel communication" on "determining and enabling the source 
communication channel for receiving the requested multicast data." Final 
Action 3, para. 7b. In the above-discussed dynamic solution, the server 
responds to a request for data sent from a client node to the server by 
informing the client node of the identity of the source communication 
channel that will carry the requested data. 

Regarding the last step of claim 1 ("using the back-channel 

communication path to multicast a message to a group of remote service 

components"), the Examiner explained that "once the client is subscribed to 

the data distribution service, server multicast message [sic] to all subscribing 

clients." Final Action 3, para. 7c. Although column 2, lines 31-30 of Dyer, 

cited as support (id.), describe "forwarding the multicast data to the 

requesting client node process," which occurs inside a client node, at page 9 

of the Answer the Examiner additionally relies on Dyer' s disclosure that "in 

the preferred embodiment, the server 5 sends to each client node 2 all 

multicast data without regard to the requirements of each client node 2," 

citing column 6, lines 1-3. It is therefore clear that the Examiner is reading 

the claimed "group of remote service components" on a plurality of client 

nodes 2 rather than on the plurality of processes 28 within a client node. 

Appellants, after quoting Dyer's above-quoted passage (col. 2, 11. 31- 
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38) that includes describing Dyer's method as including "forwarding the 
multicast data to the requesting client node process," argue that the rejection 
is improper because "the channel used to forward the multicast data appears 
to be the same channel upon which the request arrived" (Br. 11-12) 
(emphasis added). This argument is unconvincing because it is incorrectly 
assumes that the Examiner is reading the claimed "forward channel" and 
"back-channel" on communications between processes 28 and data 
distribution manager 24 within a client node. Instead, as explained above, 
the Examiner reads the claimed "forward channel communication" on a 
request sent from client node 2 to the server 6a reads the claimed "back- 
channel communication path" that is used "to multicast a message to a group 
of remote service components" on Dyer's use of a source communication 
channel to send multicast data to a plurality of client nodes 2. 

As Appellants have not shown error in the Examiner's rejection of 
claim 1, we are affirming the rejection of that claim. Because Appellants 
have not separately argued the merits of the rejections of claims 2-6, which 
depend on claim 1, we are also affirming the rejections of those claims. 
37 C.F.R. § 41.37(c)(l)(vii) (2007); In re Nielson, 816 F.2d 1567, 1572 
(Fed. Cir. 1987). 

Turning now to independent claims 7 and 13, which are argued as a 
group, we elect for consideration claim 7. 

The Examiner (Answer 5, para, e) reads the "unique remote services 
identifiers" recited in the "assigning" step on Dyer's disclosure that the 
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configuration file used by data distribution manager 24 to identify the source 
for requested multicast data "can include a static mapping of any identifier 
corresponding to a source of the requested multicast data, for example a 
proprietary network address or a network adapter address corresponding to 
the network source of the multicast data." Dyer, col. 7, 11. 28-33. Appellants 
agree that Dyer teaches that an IP address or subscriber ID/information is 
evidence of a respective unique remote service identifier (Br. 15) but argue 
that "Dyer, as discussed above, associates these identifiers with the forward 
channel, not the back-channel as is claimed." Id. (underlining omitted). 
This argument is unconvincing for the reasons given in the above discussion 
of claim 1 . 

For the foregoing reasons, we are affirming the § 102(e) rejection of 
claims 7 and 13. Because Appellants have not separately argued the merits 
of the rejections of claims 8-12 and 14-18, which depend on claims 7 and 
13, respectively, we are also affirming the rejections of those claims. 

DECISION 

The Examiner's decision that claims 1-18 are unpatentable over the 
prior art is affirmed, as is the Examiner's decision that claims 7-12 are 
unpatentable under the second paragraph of 35 U.S.C. § 112. 

No time period for taking any subsequent action in connection with 
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 
§ 1.136(a)(l)(iv) (2008). 
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AFFIRMED 



msc 
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